Top CMMC Compliance Challenges Experienced Professionals Encounter
With the deadline to comply with CMMC expected in May 2023, many in the Defense Industrial Base are scrambling to understand how to comply, the tools they need to comply, and the cost to comply.
It’s a lot to get right, and there’s a lot riding on it—companies will need to comply if they want to do business with the DoD. That’s why we’ve developed a series of blogs, checklists and other assets to help contractors manage the complexity. And while much advice is about what you should do, it’s also important to remember what not to do. Based on Egnyte’s experience working with firms tackling the CMMC 2.0 requirements, we’ve assembled the following list of the most common problems organizations encounter.
Waiting Too Late.
This is by far the most common error. Organizations assume that CMMC compliance can be achieved in a short period, perhaps as little as a week or two, because they already have cybersecurity policies and practices in place. However, experience has shown that even the most sophisticated organizations can take months to achieve and document compliance. This is because CMMC compliance is more than just an IT exercise and requires more than just a technology fix. First, detailed planning is required, often leading to additional technology, but that is only the beginning. In addition, all employees will need to be trained, while new processes and procedures will need to replace old ones. This all requires executive level engagement, not just spending approvals.
Scoping Too Broadly.
This is also a common error. Out of an abundance of caution, security engineers tend to be more inclusive than they should be in defining the scope of the infrastructure to fall under CMMC. In rare cases, they may mis-define CUI too broadly, so data is listed as CUI when it doesn’t need to be. More often, however, they simply don’t know where their CUI is, so they include more infrastructure than they need to. This may lead to including multiple repositories, and associated infrastructure and network capabilities like Identity and Access Management (IAM) services across many different systems. A broader scope often results in a much more complex and expensive path to CMMC.
Likewise, engineers sometimes target a higher CMMC level than necessary, striving for Level 2 when Level 1 is sufficient for their FCI data. Like scoping the infrastructure too broadly, striving for unnecessary levels of CMMC compliance multiplies cost, complexity, and resources. Even if level 2 compliance is necessary, it might be more practical and less disruptive to do Level 1 compliance first before attempting level 2 compliance.
Another, more subtle scoping problem, is a failure to include partners and supply chain participants in planning for CMMC compliance. For example, unique specifications sent to a supplier may contain CUI data. Therefore, that partner should be notified that they may need to comply with CMMC requirements as well. At the very least, the information needs to be passed in a secure way and employees trained on proper handling.
Having an Incomplete System Security Plan.
According to NIST, the System Security Plan (SSP) “..describes: the system boundary; operational environment; how security requirements are implemented; and the relationships with or connections to other systems.” In other words, it is a formal, written plan that documents the infrastructure (within scope), associated risks, and security controls in place (or planned) to mitigate those risks. The SSP is where auditors begin checking. They need to review complete documentation on the system under control. This calls for clearly defined and documented boundary diagrams, network architectures, services, and data flows for CUI, as well as documented processes and procedures for dealing with it.
Virtually no small- or medium-sized company has existing documentation to the depth and complexity required. Most often major components of the architecture are outsourced, and no documentation exists. Larger companies may have the people and documentation in-house, but the information can be spread across multiple IT teams rather than consolidated into one document. Whether big or small, the key point here is that you need a comprehensive inventory of exactly what falls into scope.
Lack of Detail.
When working through checklists, companies often don’t spend enough time documenting the details on key focus areas in the requirements. For example, logging should be documented to show not only that logs are collected, but also how often they are collected, how they are stored, and most importantly, how they are reviewed and analyzed. Likewise, access controls are often neglected in detailed documentation because they are complex and cross many different internal system boundaries. Documentation of access controls should include not only how they work, but the processes for how they are maintained and verified.
Finally, many security engineers often leave out detailed documentation on procedures, both for admins configuring and monitoring the system as well as users handling CUI data itself. It’s important to document proper procedures so that deviations from normal processes can be detected quickly before data is put at risk.
Lack of Continuous Monitoring.
Many organizations struggle to “climb the CMMC mountain” only to relax and become complacent at the top. CMMC requires continuous review, monitoring and improvement. The best way to do this is to choose tools and architectures that allow you to automate as much of the ongoing monitoring and maintenance as possible.
Viewing CMMC as Just a Checklist.
As stated previously, CMMC compliance is not a one-time event or simple checklist exercise. Instead, it affects people, processes, and technology, often profoundly. People may need significant training, cultures modified, new processes and procedures and even business workflows may need to change. Finally, technology needs to support the new requirements. However, this is not a static state. Over time, your business will change, which changes your risk profile and attack surface. Meanwhile, new security risks will continue to emerge, and cybersecurity solutions will evolve with them. Therefore, your SSP will need frequent review and updating to meet those risks. That’s why the DoD plans for CMMC audits to be performed on a regular basis rather than one time. CMMC compliance truly is a journey, not a destination.
Conclusion
Very few organizations successfully navigate the CMMC compliance journey on their own. They often engage consultants and contractors to supplement their internal experts. They also work with industry groups and forums to understand and interpret the standards and regulations. They may even combine efforts with partners to build compliant solutions. That’s why Egnyte has assembled a CMMC community of practitioners, security engineers, business and thought leaders, to help information flow about CMMC. Egnyte will provide educational documentation, solution information, discussions with experts, and other information to keep community members informed. For more information on CMMC and to register for the community, click here.
